IBIS Macromodel Task Group Meeting date: 12 November 2019 Members (asterisk for those attending): ANSYS: Dan Dvorscak Curtis Clark Cadence Design Systems: Ambrish Varma Ken Willis Kumar Keshavan Intel: * Michael Mirmak Keysight Technologies: * Fangyi Rao * Radek Biernacki * Ming Yan * Todd Bermensolo Mentor, A Siemens Business: * Arpad Muranyi Micron Technology: Randy Wolff * Justin Butterfield SiSoft (Mathworks): * Walter Katz * Mike LaBonte SPISim: * Wei-hsing Huang Teraspeed Labs: * Bob Ross The meeting was led by Arpad Muranyi. Justin Butterfield took the minutes. -------------------------------------------------------------------------------- Opens: - None ------------- Review of ARs: - Wei-hsing to create a slide to show how the pass-through Tx model training approach would work. - Arpad reported Wei-hsing sent out on slides. - Randy and Michael M. to invite DDR memory and controller vendors to comment on new protocols. - Michael reported he is still working on this, but he is prepared to comment to represent Intel on the issues as they are discussed. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the October 29 meeting. Walter moved to approve the minutes. Michael seconded the motion. There were no objections. ------------- Proxy Based Back Channel Flow: Wei-hsing presented his slides. He made some changes based on comments from Walter. The proposed technique uses a proprietary API between the Rx and Tx. The motivation is that File IO is not efficient and could be error prone. This approach does not require any changes to the AMI specification, and there could be some flexibility with older EDA tools. The methodology uses File IO only twice: at the beginning and when training is complete. The models to be trained are loaded as proxy models to perform the iteration needed for the training. The "getenv" C++ function can be used and the models can use DLL_ID and DLL_PATH to know the system and path information. Wei-hsing detailed the two modes of operation for training and normal simulation. The modes can be set by a Model_Specific parameter called OP_MODE. Fangyi asked if this is set by the EDA tool. Wei-hsing noted this can be handled by the user and set based on the user guide. In the normal operation mode, the models will report errors when the "config." setting file cannot be found in the case where model does not find an optimized setting. In training mode, a file is generated with the DLL_ID and DLL_PATH and obtains the path using the "getenv" function, then the training can run in the working directory. The result of the training is an output file with the AMI parameters optimized. This file can be written to the temp folder that can be seen by both the Tx and Rx. The timestep can be used to distinguish between different Tx and Rx pairs. The AMI models should be able to find this file without help from the EDA tool. The Tx and Rx can be instantiated in pairs by the EDA tool and use the timestep to match them. Fangyi asked if this will allow for multi-threading of the process. Wei-hsing stated the process ID can be used to setup multi-threading. Fangyi commented the Tx and Rx will have to be in the same thread. Wei-hsing noted the EDA tool will have to declare the Tx and Rx pairs in the correct order. Once training is done, the "config." is used. With this the Tx and Rx can have the handle for the other model. He noted this approach could work for both AMI_Init and AMI_GetWave. Arpad asked about reading the AMI parameter file and if the model would have to parse the file. Wei-hsing replied there is no parsing required by the model. The 2nd instance of the model is trained. The memory for the first model is released, and the training is transparent to the EDA tool. The model makers need to be careful of using static variables. There also could be issues with non-LTI repeaters. Walter noted he would like to have the functionality to have the Tx Init call the Rx Init and preform impulse processing. He asked how does the Tx know what memory is used by the Rx. Wei-hsing replied that the AMI_Init will only be called once, and Rx AMI_Init will have the memory handle. Walter asked how do you have the Tx DLL point to the memory. The Rx must tell the Tx to generate a pulse response with specific FFE taps. When you run the DLL code, it is memoryless. He asked how do you allow the memory to be passed between Rx and Tx. Wei-hsing replied the Rx can pass the memory back and forth with C++ classes. Fangyi stated the Rx can use the proprietary protocol to set the FFE taps with the API protocol. Wei-hsing commented all these operations are performed in the same function, so they are seamless to the EDA tool. Walter stated you are asking the model maker to write a simulator in the model. The model would have to do the Rx Init iteration. Walter noted, in his proposal, the models would be called separately and pass the information between them with strings. Wei-hsing stated his approach can be more efficient, since the iteration is between the Rx and Tx. Walter thought this approach would be more complicated, as the model makers will have to handle interprocess communication. Arpad noted this could work, with the proprietary nature of the model, when the same vendor makes both the Rx and Tx model. He asked if there is a way to extend this idea so that different vendors could use the technique. Wei-hsing stated the API needs to be documented, then both vendors can support it. Fangyi stated that the model developers could have to support different versions for different vendors if it is not standard. Wei-hsing stated that the same is true of Walter's approach. Fangyi commented the Rx will know how to load the DLL. Wei-hsing stated this should be doable by model developers. Fangyi asked if the Rx needs to load the Tx parameters. Wei-hsing stated this is done by the pass-through Tx. Fangyi asked how the metrics would be generated and if the Rx would have to run a simulation. Wei-hsing stated the metrics can be reported. Walter stated there could be several metrics used by the model. Fangyi summarized that handling the loading of the DLL inside the model is the biggest difference between the two approaches. Wei-hsing asked, in Walter's approach, how the optimized parameters get written out. Walter stated that the data is iterated over time and the optimized parameters are stored in memory. Wei-hsing asked if there is a way to use the same parameters if nothing has changed in the simulation. Walter stated the history of the simulation is saved. Wei-hsing stated that one file IO operation is inevitable, and the result is saved so that the iteration does not have to be done again. Fangyi agreed that it is required if the result must be the same. Arpad asked if we can expect to support both 32bit and 64bit machines and if we can still use wrappers which will change the process. Walter stated we had this issue on BIRD147. Arpad asked if the process ID needs to be the same. Wei-hsing stated the use of the process ID would be for filtering to the correct Rx and Tx pair. Walter stated in his approach the protocol is defined by the BCI protocol string which can be read between the Tx and Rx. Walter noted in the other approach the API is between the models. Wei-hsing noted that his approach does not require any changes to the IBIS specification. He noted it is one method that could be used. Arpad suggested we should continue this discussion next time. - Arpad: Thank you all for joining. AR: None ------------- Next meeting: 19 November 2019 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives